System for controlling processing of data passing through network gateways between two disparate communications networks

ABSTRACT

A control system is provided for controlling the aspects of data conversion and routing of data passing between two disparate communications networks. The system operates from a network-connected computer node running a software application. The computer node acquires the data protocol associated with the data en-route from one network to another and using the software application, formulates the required conversion commands and routing instructions based on information provided by the protocol signal. The generated commands are routed to the appropriate conversion nodes through which the data will pass into the next network. The conversion nodes apply the commands routed to them by the computer node to the appropriate data passing through the nodes. In one application, the control system combines the total hardware and software functions of the computer node and the conversion nodes and is provided to operate from one network-connected node.

FIELD OF THE INVENTION

[0001] The present invention is in the field of telephony communicationsand network bridging services and pertains more particularly to methodsand apparatus for controlling data-conversion capability andprotocol-command compatibility for network-bridging services.

BACKGROUND OF THE INVENTION

[0002] The field of telephony now includes connection-oriented switchedtelephony (COST) systems, which are the well-known conventionalintelligent networks provided by major telephone companies, as well asdata network telephony (DNT), which are the computer-simulated telephoneservices provided typically in the Internet, by virtue of rather recenttechnology contributed to the art enabling transparent bridging betweena COST telephony network and a Data-Packet-Network (DPN) like theInternet. With the advent of such technologies, ISPs have become moreprevalent and much more competitive with one another. A typical ISPprovides Internet connection services for clients operatingInternet-capable appliances enabled to connect to the Internet overusually telephone lines. However, with many more ISPs competing forclients, value-added services (VAS) have been developed in accordancewith available and emerging technologies. One of these services is acapability of bridging a COST network to an Internet Protocol (IP)network for bi-directional data and voice communication.

[0003] In current art, ISPs use a typically standard set of system unitsor nodes to provide connectivity and telephony bridging services. One ofthese system nodes is termed a portmaster in the art, and another iscommonly referred to as a Voice-over-Internet-Protocol (VoIP) Gateway.These nodes are more commonly referred to as network gateways orbridges. In typical implementation, one local telephone company (TELCO)carrier, which may be registered as an Incumbent-Local-Exchange-Carrier(ILEC), an Inter-Carrier-Exchange (ICX), or aCompeting-Local-Exchange-Carrier (CLEC) operates switching apparatus,which may be a Public Access Branch Exchange (PABX), or anothercompatible switching apparatus. The PABX hosted by a local TELCO carrieris typically connected to the Portmaster nodes and the VoIP nodes of anISP providing bridging services as described above. A plurality of PABXor other compatible switching apparatus are interconnected in thetelephony network, but are hosted by separate TELCOs and are connectedto separate ISP system-nodes.

[0004] More recently, many ISPs have registered as CLECs for the purposeof being able to charge other TELCOs for connection terminationservices. Such ISPs use the acquired fees to subsidize other standardservices. A well-known standard SS-7 protocol (defined in the ITUintelligent networks and Bell standards) is typically employed betweenconnected switches of competing TELCOs. In standard practice, anoriginating TELCO charges a customer for call origination and calldelivery. However, the delivery share of the customer's bill isregulated to go to a receiving TELCO or in this case an ISP registeredas a CLEC. If an ISP registered as a CLEC provides VoIP services, itwould have to pay termination fees, for example, to a receiving TELCOregistered as an ILEC for calls delivered to the telephone network. Thefees, charged back and forth by these entities work to elevatetelephone-connection costs and ISP services to customers.

[0005] What is clearly needed is a virtual switch-and-command system forproviding data processing and routing instruction directly to networkgateway nodes according to prevalent protocols, thus eliminating theneed for a local TELCO switch. Such a method would enable cost savingsrelated to the equipment costs, maintenance costs, and connectiontermination costs associated with a local switch. Cost savings realizedmay be passed on to customers creating a more competitive and attractiveservice provider.

SUMMARY OF THE INVENTION

[0006] In a preferred embodiment of the present invention an Internetservice provider (ISP) system registered as aCompeting-Local-Exchange-Carrier (CLEC) is provided, comprising achannel bank for receiving calls from a connection oriented switchedtelephony (COST) network, and separating the calls into separatechannels; at least one VoIP gateway connected to an Internet router andto one channel of the channel bank for converting voice call databetween a COST protocol and Internet protocol; at least one portmaster(PM) node connected to the Internet router and to one channel of thechannel bank for converting non-voice data between the COST protocol andthe Internet protocol; and a computer station executing a virtual switch(VS) software, the computer station connected to the Internet router andto the channel bank. The system is characterized in that the computerstation controls, via the VS software, the channel bank for separatingthe COST calls into the separate channels, and also receives and sharesSS-7 commands and data with the VoIP gateway and the PM node via theInternet router connected to the PM node and the VoIP gateway, therebyavoiding use of a telephony switching apparatus for receiving androuting calls from the COST network.

[0007] In another aspect of the invention a method for handling voiceand non-voice data calls at an Internet Service Provider (ISP) sitebetween a connection-oriented switched telephony (COST) network and theInternet, without handling the COST calls by a COST switch local to theISP site is provided, the method comprising steps of (a) substituting achannel bank for the COST switching apparatus local to the ISP; (b)operating the channel bank by a computer station in the ISP site, thecomputer station executing a virtual switch software, to channelincoming COST calls to individual ones of Voice-Over-IP (VoIP) andPortmaster gateways connected to an Internet router; and (c) sharingSS-7 commands and data from the COST network with the VoIP andPortmaster gateways by the computer station through a link to theInternet router.

[0008] The method and apparatus of the invention, taught in enablingdetail below in several embodiments, for the first time provides asystem for eliminating use of a local telephone switch for handlingcalls to individual gateways in an ISP.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

[0009]FIG. 1 is an architectural overview of a telephone exchange systemand connected network-bridging service according to prior art.

[0010]FIG. 2A is a block diagram illustrating components and function ofa portmaster according to prior art.

[0011]FIG. 2B is a block diagram illustrating components and function ofa VoIP gateway according to prior art.

[0012]FIG. 3 is an overview of a telephone-exchange system and connectednetwork-bridging system practicing virtual switching according to anembodiment of the present invention.

[0013]FIG. 4 is an overview of a telephone-exchange system and connectednetwork-bridging system practicing virtual switching according to analternative embodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014]FIG. 1 is an overview of a telephone exchange system 9 including aconnected network-bridging service 15 according to prior art.Telephone-exchange network 9 comprises three separate entities. Theseare an ILEC 11, a CLEC 13, and an ISP 15. The three described entitiestypically operate in a telephone network 10, represented herein by adotted boundary labeled telephone network. APublic-Switched-Telephony-Network (PSTN) or a private telephone networkmay be represented by domain 10.

[0015] An Internet Protocol (IP) backbone 37 is illustrated logicallyoutside of domain 10, and represents an Internet backbone or anothersuitable WideArea-Network (WAN) backbone, which supports IP. In thiscase backbone 37 is the well-known Internet backbone and its doublearrows represent connection to other backbones and other portions of theInternet network as a whole.

[0016] As described in the background section, ISP 15 provides gatewayservices for data and voice calls arriving from network 10 and enteringnetwork 37 or for data and voice calls arriving from backbone 37 andentering network 10. ISP 15 has a VoIP gateway node 29 and a portmasternode 31 resident therein and adapted to provide the above describedgateway services. VoIP gateway 29 is adapted to bridge voice calls(VoIP) and portmaster 31 is adapted to bridge data communication.

[0017] A telephony switch 17 is illustrated within ILEC 11 and isadapted to perform telephony switching functions as are generally knownin the art. Switch 17 is a PABX switch in this example. PABX 17 ishosted by a TELCO registered as an ILEC. A telephony switch 19 isillustrated within CLEC 13 and adapted to perform telephony switchingfunctions as described with reference to switch 17. Switch 19 may alsobe assumed to be a PABX switch in this example. PABX 19 is hosted by aTELCO registered as a CLEC, which is geographically local to ISP 15.PABX 17 and PABX 19 are connected through telephone network 10 by atelephony trunk 21, which is adapted to carry voice calls and datacommunication. A dotted double-arrow illustrated between PABX 17 andPABX 19 represents logical SS-7 protocol capability between bothswitches as is known in the art. SS-7 signaling may be accomplished viaa separate physical trunk or through trunk 21. In other applications,other standard protocols may be employed as are known in the art.

[0018] PABX 19 is further adapted to divide telephony trunk 21 on theILEC side into a plurality of smaller trunks 25 a-25 n on the ISP side.In this example, trunk 25 a connects PABX 19 to PM 31 for data calls. Atrunk 25 n connects PABX 19 to VoIP gateway 29 for VoIP calls. PM 31 isadapted to convert data events arriving from PABX 19 over to IP dataevents for IP delivery over backbone 37. VoIP gateway 29 is adapted toconvert voice calls arriving from PABX 19 to VoIP calls for deliveryover backbone 37. SS-7 protocol provides the rules and routinginstruction for the gateway conversion and delivery of all eventsentering the network represented by backbone 37. Similarly, all IPevents entering domain 10 from network 37 are converted and routedaccording to SS-7 protocol.

[0019] In this prior art example, an IP router 41, connected to backbone37, represents a first IP routing point in the Internet network forvoice calls arriving thereto from VoIP gateway 29 over a data trunk 35n. Similarly, an IP router 39, connected to backbone 37, represents afirst routing point for all data events arriving thereto from PM 31 overa data trunk 35 a. Trunks 35 a-n represent local data trunks. It isrecognized that there may be more gateways strategically connectedbetween PABX 19 and IP routers 41 and 39 than are illustrated in thisprior art example. The inventor illustrates only one PM 31 and one VoIPgateway 29 in this example for descriptive purpose in explanation ofthis simplified prior art configuration.

[0020]FIG. 2A is a block diagram illustrating components and functionsof PM 31 of FIG. 1. PM 31, as previously described, converts datacommunications and is a bi-directional gateway. Trunk 25 a (taken fromFIG. 1) represents all data events arriving to PM 31 or coming from PM31 on the side of domain 10. A channel bank 43 is provided within PM 31and functions to split trunk 25 a into a plurality of channels or smallgroups of channels (one or more). Channel bank 43 is typicallyimplemented as a software function for creating smaller channels orpipelines through which different types of data pass through for signalprocessing.

[0021] A Digital Signal Processing (DSP) array 49 comprises, in thisexample, DSP units a-n, which number one per channel created by channelbank 43. Each DSP unit a-n has an instance of DSP modem hardware and/orsoftware illustrated herein as SW 57 executing thereon and adapted toterminate the analog modem leg for an assigned channel and to extractthe pure data from each channel. A main controller 47 (hardwareprocessor) is provided and is control-connected to bank 43 by controlline 45. Controller 47 is also control-connected to DSP units a-n asillustrated herein by a directional arrow beginning at controller 47 andleading to DSP array 49. Controller 47 is also illustrated as connectedto a data port 51 by a control line 53. Controller 47 handles all portsupervisory duties, signaling function, call identification, security,and a host of other functions, which are known in the art. An instanceof software (SW) 55 is provided to execute on controller 47 andrepresents the control program for managing the function of PM 31.

[0022] Data bound for IP transmission and processed by array 49 arrivesat data port 51 over respective channels illustrated as solid linesconnecting each of DSP units a-n to port 51. IP data from port 51 ispassed as IP data packets over data trunk 35 a to IP router 39 (FIG. 1)and is ready to be routed over network 37 (FIG. 1). Data coming into PM31 from network 37 that is destined for domain 10 (FIG. 1) is processedin a reverse fashion accordingly.

[0023]FIG. 2B is a block diagram illustrating components and functionsof VoIP gateway 29 of FIG. 1. VoIP gateway 29 is quite similar to PM 31as far as architecture and main description of function. Trunk 25 nrepresents bi-directional transmission of voice calls to, and voicecalls from VoIP gateway 29. VoIP gateway 29 comprises a channel bank 59,a DSP array 61, a controller 65, a data port 67, and software (SW)instances 71 (DSP modem software), and 73 (control program). Controllines 63 (connecting controller 65 to channel bank 59), line 69(connecting controller 65 to data port 67), and a directional arrow(illustrating control over DSP array 61) are also illustrated in thesame fashion as in FIG. 2A.

[0024] A significant difference from VoIP gateway 29 and PM module 31 isthat DSP processing is performed more on the IP side of things. Forexample, an instance of software 73 provided as a control program forVoIP gateway 29 acts to manage conversion of analog voice over tocompressed VoIP data packets for IP transmission according typically toH.323 standard of the ITU. It can be appreciated that PM gateway 31 andVoIP gateway 29 are, other than the types of data they handle andsoftware available for process control, very similar in architecture.

[0025] The inventor has illustrated and described the prior art above inorder that one with skill in the art will appreciate the expenseinvolved, as well as the complicated trunking and channeling required toprovide adequate gateway services, which in actual practice, is morecomplex than the simple configuration described in FIG. 1.

[0026] A main goal of the present invention is to allow an ISP or otherservice-providing entity to simulate by computer the mechanicalswitching and signal processing of prior art configurations. Such anenhanced configuration is described below.

[0027]FIG. 3 is an overview of a telephone-exchange system 27 with aconnected network-bridging system 15 practicing virtualized callswitching according to an embodiment of the present invention. System 27comprises many of the same components and architecture already describedin FIG. 1. Therefore, only components which are new or modified by thepresent invention will be newly introduced and labeled with new elementnumbers herein.

[0028] Telephone network 10 comprises ILEC cloud 11 and PABX 17 as wasdescribed in FIG. 1. Trunk 21 carries events destined for EP conversionand logical trunk 23 carries the previously described SS-7 signaling.However, in this embodiment, PABX 19 (of FIG. 1) is eliminated andreplaced with an un-intelligent channel bank 75. Channel bank 75 isadapted to receive both voice and data events from PABX 17. However, thefunction of bank 75 is limited to simply dividing trunk 21 into aplurality of smaller local trunks represented herein by element number77 a-n. In this example, 77 n represents a local trunk for voice callsand is connected to VoIP gateway 29, which is the VoIP gateway describedin FIG. 1. 77 a represents a local trunk for data events and isconnected to PM 31, which is the data gateway described in FIG. 1.

[0029] A personal computer (PC) 81 is provided within the domain of ISP15 for the purpose of replacing the function of PABX 19 of FIG. 1. PC 81is connected to channel bank 75 by a bi-directional data and controlline 79. Line 79 carries the required SS-7 signaling from PABX 17. TheSS-7 signal is simply ported through bank 75, over line 79 and into PC81. PC 81 has an instance of virtual switch (VS) software 85 residenttherein. VS 85 is provided and adapted to receive SS-7 signaling asdescribed above and rout it to VoIP gateway 29 and to PM 31 accordingly.This is accomplished by a separate data connection 83, which connects PC81 to IP router 39 at backbone 37. The proper SS-7 commands for handlingarriving events are routed from IP router 39 over respective data trunks35 a and 35 n to PM 31 and VoIP gateway 29 where they may be utilized inrespective controllers 65 (FIG. 1) and 47 (FIG. 1) respectively.

[0030] By providing PC 81 running VS 85, complete processing command androuting instruction control is provided, eliminating a need for a localPABX switch. In this embodiment, ISP 15 may itself be registered as aCLEC and may host channel bank 75 in cloud 13, perhaps in corporationwith the local TELCO. Costs recovered from the elimination of PABX 19may be passed on to customers subscribing to ISP 15. Similarly, deliveryfees from ILEC 11 may be shared between the TELCO formerly hosting PABX19 and ISP 15.

[0031]FIG. 4 is an overview of a telephone-exchange system 33 andconnected network-bridging system 16 practicing virtual switchingaccording to another embodiment of the present invention. In thisembodiment it is assumed that an ISP 16 functions as a fully registeredCLEC independent from a local TELCO. Cloud 16 then comprises CLEC/ISPfunction and novel components. Telephone network 10 comprises ILEC 11and PABX 17 as described in FIG. 1 and in FIG. 2.

[0032] Trunk 23 carries events from PABX 17 to a novel componentdescribed herein as a universal gateway (UIG) 87, which is hosted by ISP16. Logical trunk 23 provides SS-7 signal as previously described. UIG87 is adapted to perform all of the function, including SS-7 signalprocessing, that was accomplished in the embodiment of FIG. 3 by channelbank 75, PC 81, VoIP gateway 29, and PM 31.

[0033] UIG 87 is a processor-controlled system having functionality thatmirrors the capability of DSP units 49 a-n and 61 a-n, which may beimplemented as separated software functions instead of hardware units.DSP modem functionality represented by software functionality 57 and 71(from FIG. 2A and FIG. 2B) may be combined into one software instance.Process control capabilities, 47 and 65, which represent controllerfunction, as described in FIGS. 2A and 2B, may be implemented on a sameprocessor within UIG 87. SW instances 55 and 73 (control programs) andVS software 85 are combined and integrated to provide all of therequired instruction for data processing and routing according to SS-7in this embodiment. In this example, it is assumed that the functions ofdata channeling as described in FIGS. 2A and 2B (43,59), as well astrunk channeling described in FIG. 3 (75) are incorporated into UIG 87.

[0034] UIG 87 represents a self-contained bi-directional gateway systemcapable of handling VoIP events as well as standard data events. UIG 87is intended by the inventor to be a scaleable system such that it may beexpanded or reduced in capacity depending on expected traffic load.Protocol for determining action states relating to VoIP related functionor PM function may be executed in a multitasking and integratedenvironment utilizing known computer-processing techniques.

[0035] In still another embodiment, PC 81 may retain VS capability 85 asdescribed in FIG. 3 and may control SS-7 processing and routing withinUIG. 87. In this case, PC 81 would obtain SS-7 signals from IP router 39over bi-directional data line 83 and communicate the appropriatecommands to UIG 87 back over line 83, IP router 39, and trunks 35 a-n.In this respect, PC 81 would be a control station for controlling andmaintaining UIG 87 and by virtue of the nature of it's connection, maybe placed anywhere on IP backbone 37.

[0036] It will be apparent to one with skill in the art that the methodand apparatus of the present invention may be practiced between any twotypes of communication networks wherein bridged data must be processedfor entry into the next network without departing from the spirit andscope of the present invention. In a preferred embodiment, the networksrepresented are a COST network (10) and an IP network (37), which is theInternet. In alternative embodiments, other types of known communicationnetworks may be bridged using the method and apparatus of the presentinvention with appropriate alterations to facilitate differing protocolsinherent in the networks.

[0037] The present invention, including method and apparatus, should beprovided the broadest possible scope under examination as there are manypossible architectural variations and unique applications. The spiritand scope of the present invention is limited only by the claims thatfollow.

What is claimed is:
 1. An Internet service provider system registered asa Competing-Local-Exchange-Carrier (CLEC), and comprising: a channelbank for receiving calls from a connection oriented switched telephony(COST) network, and separating the calls into separate channels; atleast one VoIP gateway connected to an Internet router and to onechannel of the channel bank for converting voice call data between aCOST protocol and Internet protocol; at least one portmaster (PM) nodeconnected to the Internet router and to one channel of the channel bankfor converting non-voice data between the COST protocol and the Internetprotocol; and a computer station executing a virtual switch (VS)software, the computer station connected to the Internet router and tothe channel bank; characterized in that the computer station controls,via the VS software, the channel bank for separating the COST calls intothe separate channels, and also receives and shares SS-7 commands anddata with the VoIP gateway and the PM node via the Internet routerconnected to the PM node and the VoIP gateway, thereby avoiding use of atelephony switching apparatus for receiving and routing calls from theCOST network.
 2. A method for handling voice and non-voice data calls atan Internet Service Provider (ISP) site between a connection-orientedswitched telephony (COST) network and the Internet, without handling theCOST calls by a COST switch local to the ISP site, the method comprisingsteps of: (a) substituting a channel bank for the COST switchingapparatus local to the ISP; (b) operating the channel bank by a computerstation in the ISP site, the computer station executing a virtual switchsoftware, to channel incoming COST calls to individual ones ofVoice-Over-IP (VoIP) and Portmaster gateways connected to an Internetrouter, and (c) sharing SS-7 commands and data from the COST networkwith the VoIP and Portmaster gateways by the computer station through alink to the Internet router.